CM re:Growth 2014 TOKYOで「MSP向けIAM ReadOnly権限」を話しました #cmdevio

はじめに

こんにちは。三井田です。先日、昨年の12月16日、クラスメソッドAWSチームにて「re:Growth Tokyo 2014」を開催しました。私はIAMのReadOnly権限について、運用を委託される立場からチューニングをお話をしました。

AWS謹製ポリシーテンプレート

IAMについておさらい

AWSで操作できる各アクションは、原則的に全てAPIに定義されています。そして、AWS Identity and Access Management（IAM） サービスにより、各APIアクションを許可・拒否することで、AWSリソースに対して何を実行できるかが決まって来るのです。

IAMについての様々な記事は、弊社ブログにて多数紹介されていますので、参考にしてください。
参照：『特集カテゴリーIAM』

AWS謹製のポリシーテンプレート

ポリシーテンプレートは、IAMのマネジメントコンソールから、任意のUser・Group・Roleを選ぶと、「Attach User Policy」といったボタンで開ける画面にて選択可能です。

AWSサービス全般に関する「Administrator Access」「Power User Access」「Read Only Access」を始めに、CloudFromation、CloudFront、CloudSearch、CloudTrail・・・ など、各サービス向けの「Full Access」「Read Only」などが用意されています。

MSPという立場でAWS謹製のポリシーテンプレートで課題と感じるところ

弊社では、AWSのリセラー・コンサルティングパートナーとして、多数のお客様からのお問合せの一次窓口を提供しています。まず、弊社にてお客様のAWS環境で障害や設定不備が無いかを確認して、弊社で回答できるものはそのまま回答、より詳細をAWSに確認してもらう必要があるものは、AWSサポートへエスカレーションして対応しています。

ここで、課題となってくるのが、「お客様のAWS環境で障害や設定不備が無いかを確認」するために、どのような権限が適切かという点です。

原則として弊社ではお客様の機密情報など実際のデータには触れない運用を目指してます。Read Only権限を用いるのですがAWS謹製のRead Only権限では課題と感じるところがありました。

Read Only権限はお客様の実データをも読込み可能な権限をもつ

ポリシーテンプレートのRead Only権限は、API経由で実データを取得できるサービスについては、データを取得できる権限も付与されています。S3とDynamoDBを例に挙げて説明します。

• S3
• GetObject: オブジェクト（実データ）をダウンロードできる権限です
• DynamoDB
• GetItem, BatchGetItem, Query, Scan: いずれも、Itemを取得でき、Itemには、Key-Valueペア（実データ）が含まれています

Read Only権限に含まれていない有益な権限もある

一方、通常のRead Only権限のテンプレートには含まれていない、トラブルシュートに有益な権限もあります。一例として、EC2のコンソールログを参照する権限を紹介します。

• EC2
  GetConsoleOutput: OS起動時などのコンソールログを表示する権限ですね。GUIのマネジメントコンソールですと、EC2 Instance -> Actions -> Instance Settings -> Get System Logで表示されるものです

チューニング

先に述べた課題と感じる点を、MSPという立場でどのようにチューニングしたかをいくつかの例を挙げて紹介しました。

実データ読み込み権限の剥奪

S3やDynamoDBのRead Only権限から、実際のデータ内容を参照できる権限を剥奪する例を紹介します。

S3編

S3のRead Only権限のポリシーテンプレートは以下のようになっています。今回は変更点を単純に示すため、元テンプレートとして「Amazon S3 Read Only Access」を用いて説明します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

7行目の「Get*」というワイルドカード指定で、「GetObject」も許可されてしまっているので、ここを編集していきます。

まず、他にどのような「Get〜」APIがあるのでしょうか。Amazon S3 API Referenceを確認してみます。

• Operations on Bucketsの章
• Operations on Objectsの章

ちょっと読み解くのに手間がかかりましたので、手っ取り早く、IAM Policy Simulatorを使って覗いてみます。
AWSアカウントにログインして、IAM Policy Simulator (https://policysim.aws.amazon.com/home/index.jsp?#)にアクセスすると表示されます。

「Select Service」で「Amazon S3」を選び、「Select Action」をクリックすると以下のようにActionの一覧が表示されます。Get*は、枠線で囲んだあたりに表示されています。

Get系には、「GetBucket〜」「GetLifecycleConfiguration」「GetObject」「GetObject〜」があることが確認できます。GetObject系だけワイルドカード指定を外し、GetObjectを指定しないように編集しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucket*",
        "s3:GetLifecycleConfiguration",
        "s3:GetObjectAcl",
        "s3:GetObjectTorrent",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionAcl",
        "s3:GetObjectVersionTorrent"
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

DynamoDB編

続いて、DynamoDBの例です。元テンプレートとして「Amazon DynamoDB Read Only Access」を用いて説明します。DynamoDBの利用に関係の深い、CloudWatchやData Pipeline、SNSに関する権限も含まれてますが、説明からは省略します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        <<cloudwatch:〜 を省略>>
        <<datapipeline:〜 を省略>>
        "dynamodb:BatchGetItem",
        "dynamodb:DescribeTable",
        "dynamodb:GetItem",
        "dynamodb:ListTables",
        "dynamodb:Query",
        "dynamodb:Scan",
        <<sns:〜 を省略>>
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

GetItem, BatchGetItem, Query, Scanが実データを参照できるAPIでしたので、これらを取り除けば良いことになります。

• Amazon DynamoDB API Reference「Actions」より

以下のように、シンプルに「DescribeTable」「ListTables」を残すのみとなりました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        <<cloudwatch:〜 を省略>>
        <<datapipeline:〜 を省略>>
        "dynamodb:DescribeTable",
        "dynamodb:ListTables",
        <<sns:〜 を省略>>
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

トラブルシュートに有益な権限の追加

EC2のコンソールログ参照権限

元テンプレートとして「Amazon EC2 Read Only Access」を用いて説明します。EC2と縁の深いELBやCloudWatch、AutoScailngのポリシーも記載されてますが、バッサリ省略します。最初は以下のようになっています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    <<省略>>
  ]
}

GetConsoleOutputを追加して以下のようにします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Action": "ec2:GetConsoleOutput"      
      "Resource": "*"
    },
    <<省略>>
  ]
}

その他のサービスのRead Only権限

「Read Only Access」という総括したテンプレートには、比較的新し目のサービスのRead Only権限は含まれてないことがあります。例えば、CloudWatch LogsやRoute 53 Domainsなどが該当します。ポリシーテンプレート「CloudWatch Logs Read Only Access」や「Amazon Route53 Domains Read Only Access」の内容をAPIリファレンスで紐解いて、実データアクセス・編集が出来ないような内容であれば、それぞれ適用してしまうのが良いでしょう。

CloudWatch Logsについては、Read Onlyにデフォルトで含まれる「GetLogEvents」は現状は実データと扱って含めないようにしました。

まとめ

• まずは、MSPとしてどの範囲を請け負うかのポリシーの決定が重要
• 契約で「PowerUserで運用請け負います！」と宣言することもポリシーの１つかも知れません
• しかし、セキュリティのベストプラクティスに沿って、サービス提供者として提供に必要な権限に絞るのが望ましいでしょう
• ポリシーに沿って厳密にリファレンスを紐解くのは、実は骨が折れます
• でも、旨味もあって、AWSでどのような操作が出来るのか、詳しくなり、ナレッジになります